前篇提問

• Prometheus 有寫入時間序列相關的介面？
• Prometheus 拉到資料後的處理有哪些？
• 時間序列資料如何壓縮？

本篇要來回答

• Service Discovery 的介面
• Prometheus 拉到資料後的處理方式

Service Discovery

除了使用靜態設定檔，Prometheus 也支援使用動態查詢的方式來維護標的列表。這個功能稱為 Service Discovery。
常見的平台如 Kubernetes、Consul、EC2 都已整合在 Prometheus 設定檔裡。
另有兩種一般化的實作：檔案系統或 http。

檔案系統 Service Discovery

檔案系統 Service Discovery 是在設定檔的｀file_sd_config｀裡指定一些檔名規則。Prometheus 會定期掃描符合規則的檔案，如果找到符合規則的檔案，就把檔案裡面的標的設定加入新的標的列表。
例如：

file_sd_configs:
  - files:
    - /etc/prometheus/targets/*.json
    - /etc/prometheus/targets/*.yml
  - refresh_interval: 5m

正常來說，Prometheus 會去聽這些檔案的變更事件。一但檔案有變動，就會重新載入更動的檔案。
然而有些檔案系統可能不支緩聽取變更，這時就只能仰賴 refresh_interval 設定定時掃描檔名規則列表裡的檔案是否存在。
至於檔案的格式，可以參考官方文件。

HTTP Service Discovery

HTTP Service Discovery 是在設定檔的 http_sd_configs 裡指定一個網址。Prometheus 會定期向這個網址拉取標的列表。
Http Response 的格式可以參考官方文件。

拉到資料後的處理方式

前篇提到，Prometheus 拉到資料後，會加上時間戳，並加上額外的標籤。

時間戳記選擇

Prometheus 從標的拉到資料後，會加上時間戳記。這個時間戳記是由 Prometheus 決定的，而不是標的提供的。
理由包含：

• 如果有一臺機器的時間不正確，那他會污染所有資料的正確性。
• 由 Prometheus 決定時間戳記，代表的是「取樣時間」，而不是「資料產生時間」。只要時間序列還在持續，Prometheus 就會持續取樣產生樣本點。不致使資料太稀疏。
• Prometheus 可以巧妙微調取樣時間戳，致使資料間隔均等，有利於時間序列分析和資料壓縮。

Prometheus 在取樣時間的選擇上，有兩個選擇

• 收到標的 http response 的時間
• 發出 http request 的時間

顯然由於前述資料間隔的需求，Prometheus 必然選擇發出 http request 的時間戳。這還有實作上的好處，因為這個時間戳記在 http response 讀一半時早已存在，所以每讀一個時間序列樣本值時，就可以立即寫入資料庫，不用等到這個 response 讀完。
但這個選擇也有一個缺點，就是如果 http 往返標的所花的時間太長，就可能導致發生在時間戳記之後的事件，卻被記錄在一個過去的時間戳記上。這也放大了 Collector 實作的重要性，如果 Collector 有一個巨大的 lock，導致 http handler 拿不到即時的資料，拖延了 response 的時間到新資料寫入之後，那以 request 時間戳記為取樣時間的樣本點，就會有一些資料不應該出現的新資料。

標籤處理

上篇提到，Prometheus 會在拉到資料後，加上額外的標籤。這些標籤包含預設的：

• job: 標的的名稱
• instance: 標的的實例名稱
• scheme: 標的的通訊協定
• metrics_path: 標的的 metrics 路徑
• scrape_interval: 標的的採樣間隔
• scrape_timeout: 標的的採樣逾時
• _meta*: Service Discovery標的的 metadata

和設定檔中逐條的自訂標籤覆寫規則。
預設情況下，如果標籤已經存在，Prometheus 會覆寫這個標籤。如果標籤不存在，Prometheus 會新增這個標籤。
至於像是 Pushgateway 這種 job 特例不能覆寫的狀況，可以用直接在設定檔 scrape_config 對應的 job 裡設定 honor_labels: true 來避免覆寫。